The present invention relates to the information arts. In finds particular application in relational database systems that distribute data across a plurality of computers, servers, or other platforms, and will be described with particular reference thereto. However, the invention also finds application in many other systems including distributed information systems, in information backup systems, and the like.
Relational database systems are widely used in business, government, and other organizations to record, store, process, share, and otherwise manipulate information. Because such organizations are commonly regional, national, or global in scope, the relational database is preferably accessible from regionally, nationally, or globally distributed computers, terminals, or other devices across local area networks, Internet links, wireless links, and other communication pathways. For example, worldwide offices of a corporation preferably access a single corporate database or selected portions thereof.
A problem arises in that accessing a single database by a large number of remote computer systems creates substantial communication and data processing bottlenecks that limits database speed. To overcome such bottlenecks, a distributed database system is used, in which database information is shared or distributed among a plurality of database servers that are distributed across the communication network.
A distributed database system typically includes a central database and various remote databases that are synchronized with the central database using various techniques. The remote databases can contain substantially the entire central database contents, or selected portions thereof. Moreover, transactions can be generated at the central database server or at one of the remote servers. In a commercial enterprise, for example, remote database servers at sales offices receive and generate purchase order transactions that propagate by data distribution to the central database server and in some cases to other database servers. Similarly, remote servers at billing centers generate sales invoice transactions that propagate through the distributed database system, and so forth. The central database server provides a repository for all database contents, and its contents are preferably highly robust against server failures.
To provide for recovery in the event that the central database fails, the central database can include primary and secondary database instances. The secondary database instance mirrors the primary database instance and acts as a hot backup providing failover recovery in the event of a primary database failure. Mirroring is maintained by shipping logical log files of the primary database instance to the secondary instance as they are being copied to disk or other non-volatile storage on the primary instance. The secondary instance remains in recovery mode as it is receiving and processing the shipped logical log files. Since all log records are processed at the secondary instance, the secondary instance provides a mirror image backup of the primary database instance, except for recent transactions that may not have been copied to the secondary instance yet. The primary and secondary database instances are in some cases configured such that a transaction commit is not completed at the primary until the log of that transaction is shipped to the secondary instance. Such a central database is robust against primary database failure and provides a fail-safe solution for high availability. However, it is limited in functionality, supporting only a single or limited number of synchronized secondary instances, which must be substantially compatible. For example, the primary log records should be interpretable by the secondary server without introducing substantial translation processing overhead.
Remote databases which store some or all information contained in the central database are typically maintained by synchronous or asynchronous data replication. In synchronous replication, a transaction updates data on each target remote database before completing the transaction. Synchronous replication provides a high degree of reliability and substantially reduced latency. However, synchronous replication introduces substantial delays into data processing, because the replication occurs as part of the user transaction. This increases the cost of the transaction, and can make the transaction too expensive. Moreover, a problem at a single database can result in an overall system failure. Hence, synchronous replication is usually not preferred except for certain financial transactions and other types of transactions which require a very high degree of robustness against database failure.
Asynchronous replication is preferred for most data distribution applications. In asynchronous replication, transaction logs of the various database servers are monitored for new transactions. When a new transaction is identified, a replicator rebuilds the transaction from the log record and distributes it to other database instances, each of which apply and commit the transaction at that instance. Such replicators have a high degree of functionality, and readily support multiple targets, bi-directional transmission of replicated data, replication to dissimilar machine types, and the like. However, asynchronous replicators have a substantial latency between database updates, sometimes up to a few hours for full update propagation across the distributed database system, which can lead to database inconsistencies in the event of a failure of the central database server. Hence, asynchronous replicators are generally not considered to be fail-safe solutions for high data availability.
Therefore, there remains a need in the art for a method and apparatus for fail-safe data replication in a distributed database system, which provides for reliable fail-safe recovery and retains the high degree of functionality of asynchronous replication. Such a method and/or apparatus should be robust against a failure at a critical node within the replication domain, and should ensure the integrity of transaction replications to other servers within the replication domain in the face of such a critical node failure.
The present invention contemplates an improved method and apparatus which overcomes these limitations and others.